• Add new flight controller target ASMABAK based on STM32F446RET6
• Configure MPU9255 IMU, BMP280 barometer, MAX7456 OSD on SPI/I2C
• Define 4x DShot motor outputs on TIM3 and gimbal servo outputs
• Configure 5 UARTs for receiver, GPS, MSP, VTX, and telemetry

Complete hardware configuration for ASMABAK target

• Define target board identifier and PWM output ports (8 max)
• Configure MPU9255 IMU on SPI1 with interrupt pin and magnetometer
• Setup BMP280 barometer on I2C1 bus
• Configure MAX7456 OSD on SPI2 with chip select pin
• Define 5 UART interfaces for SBUS/IBUS, GPS, MSP, VTX, and motor serial
• Configure 4 gimbal servo outputs and 2 GPIO pins for accessories
• Enable DShot ESC protocol and default features (OSD, telemetry, GPS, blackbox)

src/main/target/ASMABAK/target.h

Timer and motor output hardware definitions

• Define timer hardware mappings for 4 DShot motor outputs on TIM3
• Map gimbal servo outputs to TIM1 and TIM2 channels
• Configure motor pins PC6-PC9 and servo pins PA8, PB2, PB10, PA15

src/main/target/ASMABAK/target.c

Target configuration function stub

• Create target-specific configuration function placeholder
• Reserve space for future ASMABAK-specific initialization code

src/main/target/ASMABAK/config.c

Description

src/main/target/ASMABAK/target.h defines TARGET_IO_PORTD using BIT(2) but does not include the
header that defines BIT, so compilation depends on include order/transitive includes. This
violates the requirement that headers be self-contained and independently compilable.

Code

src/main/target/ASMABAK/target.h[R101-106]

+// IO порты
+#define TARGET_IO_PORTA         0xffff
+#define TARGET_IO_PORTB         0xffff
+#define TARGET_IO_PORTC         0xffff
+#define TARGET_IO_PORTD         (BIT(2))
+

Evidence

PR Compliance ID 1 requires headers to include the defining headers for every macro/type they use.
The new target.h uses BIT(2) in a public macro definition, while the BIT macro is defined in
common/utils.h, which target.h does not include—creating include-order dependence.

src/main/target/ASMABAK/target.h[101-106]
src/main/common/utils.h[50-58]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`src/main/target/ASMABAK/target.h` uses the `BIT()` macro (e.g., `#define TARGET_IO_PORTD (BIT(2))`) without including the header that defines it (`common/utils.h`). This makes the header non-self-contained and sensitive to include order.
## Issue Context
Compliance requires headers to be independently compilable and not rely on transitive includes. `BIT()` is defined in `src/main/common/utils.h`.
## Fix Focus Areas
- src/main/target/ASMABAK/target.h[101-106]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ASMABAK is built with target_stm32f405xg(), which hardcodes STM32F405xx compile definitions,
MCU_FLASH_SIZE=1024, and the stm32_flash_f405xg linker script. If the actual board MCU differs (per
PR description: STM32F446), this produces a binary compiled/linked for the wrong device/flash layout
and can fail to boot or overflow flash expectations.

Code

src/main/target/ASMABAK/CMakeLists.txt[1]

+target_stm32f405xg(ASMABAK HSE_MHZ 8)

Evidence

The target’s CMake macro selection directly controls MCU preprocessor defines and the linker
script/flash size assumptions used for the whole firmware image.

src/main/target/ASMABAK/CMakeLists.txt[1-1]
cmake/stm32f4.cmake[103-120]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ASMABAK` is built with `target_stm32f405xg(...)`, which sets `STM32F405xx`, `MCU_FLASH_SIZE=1024`, and uses the `stm32_flash_f405xg` linker script. For an STM32F446-based board this is the wrong MCU configuration and can generate an invalid binary.
### Issue Context
The MCU selection is centralized in `cmake/stm32f4.cmake`. `ASMABAK` currently reuses the F405 macro.
### Fix Focus Areas
- src/main/target/ASMABAK/CMakeLists.txt[1-1]
- cmake/stm32f4.cmake[103-140]
### What to change
- Add a new CMake function for STM32F446 (e.g. `target_stm32f446xe(...)` or similar) that:
- Defines the correct MCU macro (e.g. `STM32F446xx`) and correct `MCU_FLASH_SIZE` for the intended part.
- Uses an appropriate startup file and linker script for F446.
- Uses the correct SVD (`STM32F446` exists under `dev/svd`).
- Update `ASMABAK/CMakeLists.txt` to call the new STM32F446 function instead of `target_stm32f405xg(...)`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

src/main/target/ASMABAK/target.h defines USE_MAG_MPU9250 but does not define USE_MAG, so the entire
compass subsystem is compiled out and the onboard AK8963 (via MPU925x) will not be usable. This
breaks MAG/heading features for this target.

Code

src/main/target/ASMABAK/target.h[R18-26]

+#define MPU9250_CS_PIN          PC5
+#define MPU9250_SPI_BUS         BUS_SPI1
+#define USE_IMU_MPU9250
+#define IMU_MPU9250_ALIGN       CW0_DEG        // подберите по ориентации платы (CW0/CW90/CW180/CW270)
+
+#define USE_MAG_MPU9250
+#define MAG_MPU9250_ALIGN       CW0_DEG
+
+#define GYRO_INT_EXTI_PIN       PC4            // прерывание от гироскопа (EXTI4)

Evidence

The compass implementation is guarded by USE_MAG, and reference MPU9250 targets define USE_MAG in
addition to USE_MAG_MPU9250.

src/main/target/ASMABAK/target.h[18-26]
src/main/sensors/compass.c[64-68]
src/main/target/CLRACINGF4AIR/target.h[47-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ASMABAK/target.h` enables the MPU925x magnetometer driver via `USE_MAG_MPU9250`, but does not define `USE_MAG`. The compass subsystem is wrapped in `#ifdef USE_MAG`, so magnetometer support is effectively disabled.
### Issue Context
Other MPU9250-based targets define `USE_MAG` (and sometimes `USE_MAG_MPU9250` explicitly).
### Fix Focus Areas
- src/main/target/ASMABAK/target.h[18-26]
- src/main/sensors/compass.c[64-68]
### What to change
- Add `#define USE_MAG` in `ASMABAK/target.h`.
- Optionally remove redundant `USE_MAG_MPU9250` (since `common_post.h` can define it when `USE_MAG_ALL` is used), but only if you also define `USE_MAG_ALL` and you want auto-selection.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ASMABAK enables USE_LED_STRIP with WS2811_PIN=PA15 while also defining/using PA15 as a servo output
(GIMBAL_ZOOM on TIM2_CH1). Additionally, the target provides no timerHardware entry with
TIM_USE_LED, so WS2811 init can’t bind a valid LED timer and will not initialize the LED strip.

Code

src/main/target/ASMABAK/target.h[R87-96]

+#define USE_LED_STRIP
+#define WS2811_PIN              PA15                // если есть LED-стрип (можно изменить)
+
+// Gimbal (подвес камеры) — PWM
+#define USE_SERVOS
+#define GIMBAL_PITCH_PIN        PA8                 // TIM1_CH1
+#define GIMBAL_ROLL_PIN         PB2                 // TIM2_CH4
+#define GIMBAL_YAW_PIN          PB10                // TIM2_CH3
+#define GIMBAL_ZOOM_PIN         PA15                // TIM2_CH1 (если нужно)
+

Evidence

WS2811 initialization requires a timerHardware entry with TIM_USE_LED; ASMABAK’s timer table
contains only motor/servo usages. PA15 is declared for both WS2811 and servo, creating an
unresolvable resource conflict if both are intended to work.

src/main/target/ASMABAK/target.h[87-96]
src/main/target/ASMABAK/target.c[7-18]
src/main/drivers/light_ws2811strip.c[123-133]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`WS2811_PIN` is set to `PA15`, but `PA15` is also used as a servo output (`TIM2_CH1`) in `timerHardware[]`. The target also lacks any `timerHardware[]` entry flagged with `TIM_USE_LED`, which WS2811 needs to initialize.
### Issue Context
`ws2811LedStripInit()` looks up the timer by `WS2811_PIN` and requires a `TIM_USE_LED`-capable timer entry; otherwise it falls back to `timerGetByUsageFlag(TIM_USE_LED)` and returns early when none exist.
### Fix Focus Areas
- src/main/target/ASMABAK/target.h[87-96]
- src/main/target/ASMABAK/target.c[7-18]
- src/main/drivers/light_ws2811strip.c[123-133]
### What to change
- Pick one of:
- Move `WS2811_PIN` to a free timer-capable pin and add a corresponding `DEF_TIM(..., TIM_USE_LED, ...)` entry.
- Or keep WS2811 on `PA15` and change the gimbal zoom output to a different pin/timer.
- Or if LED strip is not present on the board, remove `USE_LED_STRIP` and `WS2811_PIN` from the target.
- Ensure there is exactly one viable timerHardware entry flagged `TIM_USE_LED` for WS2811.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

All newly added ASMABAK files are missing a trailing newline, which can cause noisy diffs and
tooling issues (formatters/linters/patch applications).

Code

src/main/target/ASMABAK/target.h[107]

+#define DEFAULT_FEATURES        (FEATURE_OSD | FEATURE_CURRENT_METER | FEATURE_VBAT | FEATURE_TELEMETRY | FEATURE_BLACKBOX | FEATURE_GPS)

Evidence

The PR diff explicitly marks “\ No newline at end of file” on each added ASMABAK file.

src/main/target/ASMABAK/target.h[1-107]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New files under `src/main/target/ASMABAK/` are missing a trailing newline.
### Issue Context
The git diff marks `\ No newline at end of file` for these additions.
### Fix Focus Areas
- src/main/target/ASMABAK/CMakeLists.txt[1-1]
- src/main/target/ASMABAK/config.c[1-6]
- src/main/target/ASMABAK/target.c[1-20]
- src/main/target/ASMABAK/target.h[1-107]
### What to change
- Ensure each file ends with a single newline character.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools